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SUMMARY 


A  relocating  assembler  and  a  linking  loader  have  been  programmed  for  the  TX-2  To 
provide  more  convenient  graphical  facilities,  a  new  Extended  Graphic  Subsystem  has  been  writ¬ 
ten,  Recent  display  hardware  additions  to  TX-2  have  included  a  color  display,  storage  tubes, 
and  a  commercial  ARDS  console. 

Application  program  work  on  semiconductor  mask  design  has  continued,  with  current  work 
at  an  80  gate/chip  level.  Initial  exploratory  work  on  a  design  data  system  has  been  performed. 
Application  of  the  LX-1  microprocessor  to  vocoder  and  display  control  problems  has  been  stud¬ 
ied.  Experimental  systems  for  Interactive  Computer-Mediated  Animation  and  Real-Time  Input 
saving  have  been  completed.  Performance  measurements  on  the  APEX  system  are  being  con¬ 
ducted  and  the  data  analyzed.  A  stand-alone  circuit-testing  terminal  with  a  small  computer  is 
under  development. 
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GLOSSARY 


ALGOL 

ambit/g 

A  high-level  algebraic  problem-solving  language 

A  graphical  programming  language  for  manipulation  of  directed 
graphs 

APEX 

TX-2  time-sharing  executive 

ARDS 

Advanced  Remote  _Display  System 

BCPL 

Basic  Combined  Programming  Language  —  an  intermediate 
level  language  for  computer  programming 

DAP 

Display  Assembly  Program 

EGS 

Extended  Graphic  Subsystem 

LEAP 

Language  for  Expressing  Associative  Procedures  —  an  ALGOL- 
like  TX-2  programming  language 

LSI 

Large-Scale  integrated  circuit  technology 

LX  -  1 

A  prototype  microprocessor  being  constructed  at  Lincoln 
Laboratory 

ML 

A  microprogramming  assembly  language 

ROM 

Read-only  memory 

TAP 

TX-2  Assembly  Program 

vi 


GRAPHICS 


I.  LANGUAGES  AND  SYSTEMS 

A.  Assembler  and  Loader 

An  integrated  relocatable  code  system  has  finally  been  created  for  the  TX-2  comprising  the 
BCPL  compiler,  a  new  relocatable  assembler,  and  a  linking  loader.  The  output  of  the  BCPL 
compiler  is  a  text  file  of  assembly  code  similar  in  form  to  any  created  by  hand.  The  assembly 
code  then  passes  to  the  new  TAP  (TX-2. ^Assembly  Program)  assembler  which  produces  a  relative 
binary  file  containing  binary  code,  relocation  bits,  and  symbolic  linkage  information.  The  link¬ 
ing  loader  combines  relative  binary  files  to  produce  executable  TX-2  code. 

This  new  system  has  been  used  to  create  both  the  BCPL  compiler  (written  itself  in  BCPL) 
and  the  EGS  described  below.  In  addition,  the  TAP  assembler  with  modifications  serves  as  an 
assembler  on  TX-2  for  the  16-bit  testing  terminal  computer. 

B.  Extended  Graphic  Subsystem  (EGS) 

1  Introduction 

During  the  past  year  at  Lincoln  Laboratory,  a  number  of  interactive  graphic  programs  have 
been  written  on  TX-2.  These  programs  included  the  mask  program,  a  logic  input  program, 
AMBIT/G,  and  an  event  simulator.  All  had  one  significant  feature  in  common  —  provision  for 
the  users  to  draw  a  picture  into  the  computer  using  the  Sylvania  Data  Tablet  and  the  character 
recognizer.  A  " windowing"  capability  is  not  available  in  the  TX-2  hardware  and  is  not  provided 
by  the  display  executive  in  APEX.  Each  programmer  was  required  to  provide  his  own  windowing 
facility  to  allow  users  to  input  pictures  larger  than  10  inches  square.  While  this  task  is  not  dif¬ 
ficult  to  accomplish  with  LEAP,  the  duplication  of  effort  is  unnecessary.  The  EGS  is  designed 
to  provide  this  service  to  user  programs  under  APEX. 

2.  EGS 

EGS  is  a  subsystem  under  APEX  and  runs  in  user  mode.  The  EGS  contains  five  sections: 
a  linkage  and  data  structure  package,  a  Display  Assembly  Program  (DAP)  interpreter,  a  clipper 
program,  a  display  data  generator,  and  a  user- specified  package  of  graphic  entity  definitions. 

a.  Entity  Definitions 

The  definitions  of  graphic  entities  are  procedures  written  in  DAP  by  the  user  of  EGS  for 
his  specific  application.  A  simple  procedure  would  take  one  point  parameter  and  produce  dis¬ 
play  data  for  that  point.  A  more  complicated  procedure  may  take  two  point  parameters  and  gen¬ 
erate  the  data  which  describe  an  arrow,  or  a  ruler.  The  user  may  even  write  a  procedure  which 
takes  N  points  and  generates  the  data  which  describe  all  straight  lines  connecting  any  two  points. 

b.  DAP 

These  procedures  are  coded  by  the  application  programmer  in  DAP.  The  EGS  system  in¬ 
cludes  an  interpreter  to  translate  DAP.  All  data  values  in  DAP  are  points  (i.e.,  X,  Y  coordinate 
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pairs).  The  simulated  machine  interpreting  DAP  contains  28  general  registers  for  temporary 
storage  (RO  R27)  and  several  special  registers.  There  is  also  a  stack  for  passing  parameters. 
The  format  of  a  standard  DAP  instruction  is  OPCODE  REGISTER. 

Of  the  four  DAP  opcodes  which  generate  display  data,  two  generate  data  for  vectors  and  two 
for  characters.  They  are: 

DRAW  TO  A  POINT  DPT 

DRAW  BY  DELTAS  DDL 

CHARACTERS  CHAR 

CHARACTERS  CLIPPED  CHARC 

c.  Automatic  Windowing 

All  position  information  from  the  DAP  interpreter  program  passes  through  the  clipper  pro¬ 
gram.  The  clipper  provides  the  automatic  windowing  facility  for  EGS. 

All  parameters  passed  to  the  DAP  entity  definition  procedures  are  in  terms  of  "floor”  coor¬ 
dinates  (raw  position  data).  These  coordinates  are  integers  with  the  range  =f377777  (=f1  30000^ q). 
The  raw  position  data  are  translated  and  scaled  by  a  user-specified  offset  and  scale  factor. 

These  new  position  data  are  then  clipped  to  lie  within  a  user-specified  window  on  the  scope  face. 
The  windowing  information  which  controls  the  actions  of  the  clipper  is  contained  in  a  4-element 
array. 


d  Picture  Generation 

Two  types  of  calls  can  be  made  on  EGS  to  generate  a  picture  on  the  scope: 

GENERATE 

DISPLAY 

GENERATE This  call  takes  a  list  of  parameters,  pushes  them  onto  the  pa¬ 
rameter  stack,  and  then  activates  the  DAP  procedure  specified  in  the  call.  The  activation  of  any 
DAP  procedure  will,  in  general,  process  a  number  of  parameters  from  the  parameter  stack  and 
generate  display  data  which  will  be  added  to  the  output  buffer 

DISPLAY :—  This  call  takes  two  Integer  parameters:  an  item  number,  and  a 
group  number.  All  display  data  currently  in  the  output  buffer  are  passed  to  the  APEX  display 
executive  as  the  specified  item  in  the  specified  group  This  call  does  not  clear  the  output  buffer 
and,  in  fact,  may  be  followed  by  more  GENERATE  and  DISPLAY  calls.  Each  GENERATE  call 
will  add  more  data  to  the  buffer.  Each  subsequent  DISPLAY  call  will  display  the  data  accumu¬ 
lated  in  the  output  buffer. 

The  DAP  regeneration  program  is  activated  by  a  REGENERATE  call  to  EGS.  This  call  takes 
a  list  of  parameters  containing  the  new  values  of  the  clipping  array.  The  execution  of  this  call 
performs  two  functions-  first,  it  replaces  the  old  values  of  the  clipping  array  with  the  new  ones; 
second,  it  regenerates  the  picture  on  the  scope  to  reflect  the  changes  in  the  clipping  array.  A 
REGENERATE  call  may  be  made  at  any  time. 

e.  Other  Calls  on  EGS 

There  are  three  other  calls  on  EGS  currently  available:  DELETE,  INIT,  and  CLEAN. 

A  DELETE  call  takes  the  same  parameters  as  DISPLAY:  an  item  number,  and  a  group 
number.  The  action  of  this  call  is  to  delete  the  specified  item  from  the  sequence  64  display 
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structure  and  the  DAP  regeneration  program.  An  item  number  of  zero  will  cause  all  items  in  the 
specified  group  to  be  deleted  and  will  remove  the  group  from  the  sequence  64  display  structure. 

INIT  initializes  EGS  and  sets  up  an  ephemeral  file  for  EGS  to  use  for  impures.  CLEAN  also 
initializes  EGS,  but  it  differs  from  INIT  in  that  it  assumes  the  ephemeral  file  to  be  already  set 
up* 

C.  Display  Hardware 

1  Color  Display 

Experiments  with  a  two-layer  red-green  phosphor  in  a  standard  TX-Z  display  tube  are  under 
way.  The  color  is  switched  by  changing  the  accelerating  potential  of  the  CRT;  circuitry  for  ac¬ 
complishing  a  rapid  change  of  5  kV  has  been  built  and  operated.  The  change  in  accelerating  po¬ 
tential  necessitates  an  accompanying  change  in  the  deflection  sensitivity,  and  circuits  for  this 
have  been  developed. 

The  color  tube  has  been  tested  on  TX-Z  with  the  mask  layout  program.  Changes  to  support 
this  display  were  temporarily  made  in  the  executive  program  An  important  function  in  the  mask 
program  is  the  selection  of  a  set  of  components  as  command  operands.  At  present,  selection  of 
components  is  indicated  by  an  X  displayed  on  top  of  each  designated  part.  The  color  display 
was  used  to  replace  this  indicator  with  a  color  shift  The  basic  display  is  green,  and  selected 
components  change  to  red.  Initial  results  appear  promising  and  further  experiments  will  be 
conducted. 

Z.  ARDS  Terminal 

Provision  has  been  made  for  the  connection  of  an  ARDS  terminal  to  TX-Z.  The  ARDS  was 
established  as  another  console  and  placed  into  regular  service.  User  acceptance  has  been  en¬ 
couraging,  with  the  rapid  display  of  text  a  motivating  factor.  A  public  program  accessible  from 
LEAP  has  been  written  which  allows  pictures  to  be  drawn  by  programs. 

3.  Storage  Tubes  at  TX-Z  Consoles 

Storage-tube  displays  have  been  added  to  the  TX-Z  consoles  and  are  used  by  various  pro¬ 
grams.  Several  noninteractive  graphical  output  programs  (e.g.,  .data  plotting)  have  been  mod¬ 
ified  to  utilize  this  hardware.  The  storing  of  a  reference  picture  on  the  storage  scope  by  the 
mask  program  has  also  been  found  useful.  In  addition,  a  storage  display  has  been  placed  in  the 
Transistor  lab  in  conjunction  with  the  TIC  (Testing  Integrated  Circuits)  terminal.  Parameter 
plots  can  be  viewed  immediately  after  measurements  are  made  on  actual  circuit  components. 

4.  Character  Generator 

A  new  character  generator  is  under  development  using  the  high-speed  decoders  produced 
for  the  conic  generator.  This  character  generator  is  a  direct  replacement  for  the  commercial 
one  already  installed,  and  its  improved  features  include  flexible  character  specification  in  a 
read-only  memory,  and  variable  speed  generation  required  for  efficient  utilization  with  both 
refreshed  and  storage  scopes. 
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IL  GRAPHICS  AND  APPLICATIONS 


A.  Semiconductor  Mask  Design 

Mask  design  on  the  TX-2  continues  at  a  steady  pace.  Completed  mask  designs  used  to  fab¬ 
ricate  circuits  include: 

(1)  A  new  version  of  the  read-only  memory, 

(2)  A  simple  3-input  AND  gate  design  for  the  collector  diffused  isolation 
(CDI)  technology, 

(3)  Beam-lead  and  face-down  bonding  masks  for  use  in  the  heat  dissi¬ 
pation  studies, 

(4)  A  fabrication  process  evaluation  chip, 

(5)  Masks  used  in  the  face-up  bonding  investigations, 

(6)  A  basic  80-gate  array  which  will  have  custom  metallization  applied 
to  it  in  order  to  implement  a  wide  range  of  functions. 

Several  custom  metallizations  are  in  the  final  design  stages  for  the  80-gate  array.  These 
include  a  circuit  to  provide  data  on  gate  fanout  vs  gate  time  delay  and  circuits  for  the  micro¬ 
processor's  adder,  register,  and  multiplier  function. 

Microphotographs  of  the  actual  timing  gate  chain  chip,  previously  designed  on  the  TX-2, 
are  found  in  Figs.  1  and  2. 

A  portion  of  the  support  of  the  Semiconductor  Mask  design  software  has  entered  the  "fine 
tuning”  stage.  Recent  software  modifications  have  not  changed  the  program's  input/output  char¬ 
acteristics  but  have  improved  the  utilization  of  the  TX-2's  cpu,  memory,  and  drum  memory. 

For  example,  the  program  was  modified  to  use  integer  representations  of  the  mask  component 
coordinates  as  opposed  to  real  number  representations.  This  change,  not  affecting  the  pro¬ 
gram's  capabilities,  accelerated  the  program  by  30  percent,  primarily  because  the  TX-2  has  no 
floating-point  hardware;  this  change  typifies  a  major  portion- of  the  support.  The  measurements 
for  changes  were  done  using  the  system  measuring  hardware  on  the  TX-2. 

Other  software  support  includes  new  methods  of  generating  CalComp  plots  of  the  designed 
masks  and  a  means  of  documenting  what  components  arc  where  on  a  mask  set.  The  mask  design 
software  has  been  factored  into  separate  entities  representing  application-dependent  and 
application-independent  information.  The  application-dependent  information  represents  com¬ 
ponent  definitions  for  a  particular  circuit  fabrication  method  such  as  bipolar,  CDI,  or  MOS;  the 
application-independent  information  represents  the  program's  control  and  structural  skeleton. 
These  entities  are  kept  as  distinct  text  files  and  are  merged  to  form  the  desired  mask  program. 
This  setup  allows  the  application-independent  information  to  be  kept  in  one  place,  as  opposed  to 
being  replicated  in  several  different  places,  and  insures  that  any  application  program  has  the 
most  current  copy  of  the  control  section. 

This  factoring  has  spawned  other  uses  of  the  control  and  structural  skeleton  of  the  mask 
design  software.  For  example,  an  application  program  for  designing  a  Naval  ship's  compart¬ 
ments  was  constructed  by  defining  the  appropriate  application-dependent  information.  This  pro¬ 
gram,  which  required  four  man  hours  for  construction,  was  described  and  demonstrated  for  the 
Department  of  the  Navy,  Naval  Ship  Systems  Command. 

The  "production”  use  of  the  mask  design  software  has  recently  required  2  hours  a  day  during 
which  it  is  necessary  to  insure  maximum  response  to  a  mask  designer's  requests.  As  an  ex¬ 
periment  during  these  hours,  APEX  has  been  conditioned  to  examine  the  status  of  console  1  (the 
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mask  user)  in  determining  its  scheduling  strategy.  Status  is  determined  by  the  position  of  a 
switch  in  the  system  configuration  register.  If  console  1  "is  king,"  then  it  receives  all  the  cpu 
and  memory  that  it  asks  for  and  can  use.  Console  l's  programs  and  data  are  brought  into  mem¬ 
ory  from  the  drum  and  given  free  reign  over  the  cpu.  As  a  direct  result,  other  programs  and 
data  are  removed  from  main  memory  and  put  onto  the  drum. 

When  console  1  has  completed  its  computation,  the  other  consoles  are  scheduled  in  the  nor¬ 
mal  mode.  Typically,  these  other  consoles'  programs  and  data  are  on  the  drum.  Console  l's 
programs  and  data  must  be  swapped  out  (they  occupy  at  least  60  percent  of  memory)  and  other 
programs  and  data  swapped  in.  This  is  a  very  slow  process.  Console  1  can  wait  up  to  5  seconds 
before  its  programs  and  data  are  available  in  main  memory.  This  wait  is  a  fatiguing  one  for  the 
mask  designer  and  is  not  tolerated.  Thus,  in  this  instance,  a  critical  TX-2  resource  is  its  main 
memory  rather  than  its  cpu 

B.  Design  Data  System 

A  trial  implementation  of  a  design  data  system  has  been  created  on  TX-2.  This  work  is 
patterned  after  the  system  developed  at  Stanford  Research  Institute  but  with  a  heavy  bias  toward 
the  local  style  of  graphical  interaction.  The  ultimate  aim  is  to  create  a  computer-based  aid  for 
recording  and  manipulating  the  complex  data  involved  in  a  system  design.  Work  to  date  has  pro¬ 
duced  a  program  which  can  be  used  to  explore  the  kind  of  interactive  assistance  needed.  The 
program  is  written  in  LEAP  and  is  coupled  to  the  input  saving  facility  also  described  in  this 
report. 


1 .  Data  Concepts 

Information  about  a  design  is  contained  in  a  collection  of  pictures,  each  containing  any  num¬ 
ber  of  boxes  and  lines.  These  components  are  normally  used  to  construct  some  kind  of  a  dia¬ 
gram  (Fig.  3).  Arbitrary  selections  of  text  can  be  placed  in  a  box  or  attached  to  a  line.  Routines 
adjust  display  of  text  to  the  confines  of  a  box.  Pictures  can  be  viewed  with  normal  zoom  and  off¬ 
set  controls.  Each  picture  has  a  name  and  can  have  a  descriptive  title. 

Connection  between  related  pictures  is  provided  by  several  mechanisms.  A  box  may  be  an 
entry  point  to  a  subordinate  picture  and,  if  so,  has  a  "P"  at  its  upper  left  corner.  Making  an 
appropriate  drawn  command  on  such  a  box  causes  the  link  to  be  traversed  and  the  subordinate 
picture  to  be  displayed.  Links  by  name  to  pictures  are  also  possible.  Either  the  first  word  of 
text  in  a  box  or  the  word  following  "(SEE"  in  the  text  can  be  used  as  a  picture  name  for  cross 
referencing.  Appropriate  commands  drawn  on  top  of  boxes  will  invoke  any  of  the  three  linking 
mechanisms.  A  linking  command  to  a  nonexistent  picture  creates  a  new  blank  picture  appropri¬ 
ately  connected  into  the  picture  structure. 

The  box  linkages  provide  a  hierarchy  of  pictures  descending  from  an  initial  picture.  An 
arbitrary  fanout  is  available  at  any  level  since  any  number  of  boxes  can  be  included  in  that  pic¬ 
ture  and  used  as  entries  for  subordinate  pictures.  It  is  possible  to  restructure  these  links  and 
make  two  separate  boxes  (perhaps  in  different  pictures)  have  the  same  subordinate  picture. 

Thus,  the  tree  hierarchy  can  in  principle  be  turned  into  arbitrary  connections.  However,  the 
box  linkage  mechanism  is  intended  to  provide  hierarchical  ordering  to  pictures.  In  contrast, 
the  name  linkage  mechanism  provides  arbitrary  links  across  the  picture  structure  at  will. 
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2.  Program  Operation 

Commands  to  this  program  are  mainly  given  by  drawn  marks  on  the  Sylvania  tablet  and  fall 
into  several  broad  categories: 

(a)  Picture  Element  Manipulation:  Commands  to  make,  move  and  delete 
boxes,  lines,  and  text  and  to  control  picture  viewing  (zoom,  etc.) 

(b)  Structure  Linking:  Commands  to  move  the  display  to  selected  pictures 
in  the  structure  and  to  modify  the  structure 

(c)  Storage  Scope  Control*  Commands  to  place  various  pictures  or  picture 
parts  on  the  console  storage  scope  for  reference  purposes 

(d)  Administrative:  Commands  to  save  or  read  in  a  structure  from  disk 
or  to  go  to  the  symbol  trainer,  etc. 

Trial  use  of  this  system  has  just  begun  to  obtain  experience  with  the  various  features.  As 
with  any  program  of  this  type,  it  is  a  difficult  task  to  discover  just  what  kinds  of  computer  help 
are  really  useful  and  which  initial  ”good  ideas”  never  get  used. 

A  critical  and  as  yet  unsolved  problem  is  that  of  indexing.  When  working  with  this  system, 
an  overview  of  the  structure  created  is  necessary.  Schemes  for  obtaining  a  list  of  the  existing 
pictures  are  available,  but  more  are  needed. 

C.  Microprocessor  Applications 

1  A  Microprogrammed  Digital  Vocoder 

a.  Introduction 

The  feasibility  of  using  the  microprocessor  under  development  by  Group  23  as  a  digital 
vocoder  analyzer  and/or  synthesizer  has  been  investigated.  An  implementation  of  the  micro¬ 
processor  as  an  analyzer  only  (with  no  pitch  detection)  was  microcoded  and  simulated.  Hard¬ 
ware  modifications  to  the  microprocessor  to  enable  real-time  operation  are  described  below. 

b.  Short  Functional  Description  of  the  Microprocessor  LX-1 

Two  versions  of  the  microprocessor  are  contemplated.  The  first,  called  the  prototype, 
will  have  an  80-nsec  control  memory  cycle  time.  The  second  version,  using  LSI  technology, 
will  have  a  control  memory  cycle  time  which  is  five  times  faster. 

The  LX-1  microprocessor  is  described  in  a  memo  by  G.  D.  Hornbuckle,  an  excerpt  of 
which  follows: 

"  The  three  major  components  of  LX-1  are  a  64  bit  x  256  word 
control  memory  (sometimes  referred  to  as  the  read-only  memory 
or  ROM),  a  set  of  sixteen  16-bit  registers,  and  several  function 
units  which  perform  operations  on  the  data  in  the  registers.  Each 
of  the  registers  is  connected  to  three  buses  called  A,  B,  and  D 
(see  Fig.  4).  The  A  and  B  buses  are  the  data  paths  from  the  reg¬ 
isters  to  the  function  units,  and  the  D  bus  is  the  data  path  from  the 
function  units  to  the  registers.  Control  signals  come,  for  the  most 
part,  from  the  control  memory." 


*G.  D.  Hornbuckle,  ”LX-1  Reference  Manual,”  private  communication. 
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There  is  also  a  writeable  1 6-b it  x  128-word  scratchpad  memory,  accessible  in  one  control 
memory  cycle  time  (80  nsec).  Thus,  some  example  operations  on  the  LX-1  are 

A  •  BUS/3-B-  BUS-D*  BUS 

where  A- BUS,  B-BUS,  and  C  BUS  are  register  numbers,  and  /3  implies  a  3-bit  right  shift 
A 14  — D-  BUS 

i.e  ,  read  the  value  of  scratchpad  location  14  onto  the  D  bus. 

Branching  in  LX-1  is  achieved  by  setting  and  testing  six  special  bits,  denoted 

C  carry  bit 

Z  zero  bit  (Z  =  1  =>  word  is  zero) 

H  high-order  bit 
L  low-order  bit 
S  bit  1 
F  overflow 

Thus, 

A*  BUS  +  B*  BUS— D*  BUS,  Z,  F 

will  cause  the  Z  and  F  bits  to  be  set  according  to  the  result  of  the  addition; 

LOOP(l)  A  BUS— D-BUS,  C/LOOP(C) 

LOOP(O) 

will  cause  a  branch  to  the  label  according  to  the  value  of  C. 

c.  Short  Functional  Description  of  the  Digital  Vocoder 

The  vocoder  is  described  in  papers  by  W.  M.  Anderson,  Jr.,  and  by  T.  Bially.^  A  short 
outline  of  the  analyzer  is  given  here  (quoted  from  T.  Bially,  "Structure  of  a  Digital  Channel 
Vocoder" ). 

"The  spectrum  analyzer  portion  of  the  vocoder  consists  of 
thirty-two  filters  of  the  form  shown  in  Fig.  5.  Input  speech  is 
sampled  at  a  ten  kilohertz  rate  (once  every  lOO^xsec)  and  is  si¬ 
multaneously  modulated  by  two  reference  sinusoids  whose  fre¬ 
quency  is  equal  to  the  center  frequency  of  the  filter  in  question. 

Fifty  successive  samples  at  the  output  of  each  modulator  are 
summed  and  added  to  the  sum  of  the  fifty  output  samples.  Thus 
at  time  99T  the  signal  at  point  x  in  Fig.  5  has  the  value 

99 

Yj  S(kT)  cos  nw^kT 
k=0 

and  that  at  point  y  is 


*  W.  M.  Anderson,  Jr.,  "Specification  of  a  Digital  Vocoder  System,"  presented  at  Acoustical 
Society  of  America,  Cleveland,  19-22  November  1968. 

tT  Bially,  "Structure  of  a  Digital  Channel  Vocoder,"  to  be  presented  at  IEEE  International 
Conference  on  Communications,  Boulder,  Colorado,  9-11  June  1969. 
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99 

Yj  S(kT)  sin  nwQkT 
k=  0 


The  square  root  of  the  sum  of  the  squares  of  these  two  values  is 
computed  at  point  z: 


S(kT)  cos  nw0kT 


/"  \2 

+  I  £  S(kT)  sin  nwQkT  j 

'k=0  ' 


99 

1 


S(kT)e 


jnQkT 


k=0 


Every  five  milliseconds  then,  the  signal  at  z  is  numerically 
equal  to  the  magnitude  of  the  nw^  component  of  the  discrete 
Fourier  transform  of  the  preceding  ten  milliseconds  of  S(kT). 

.  .  .  Four  successive  outputs  are  averaged  to  yield  the  final  out¬ 
put  once  every  20  milliseconds.  The  thirty-two  analyzer  chan¬ 
nels  are  spaced  one  hundred  cycles  wide.  The  center  frequencies 
are  100,  200,  .  .  .  ,  3200Hz.” 

Thus,  every  twenty  milliseconds,  we  have  thirty-two  values  corresponding  to  the  channel 
signals  for  the  current  interval. 

"These  are  encoded  into  a  total  of  thirty  two  bits  by  a  com¬ 
bination  of  logarithmic  quantization,  averaging  of  adjacent  chan¬ 
nel  values  at  the  high  frequency  end  of  the  spectrum,  and  a  lin¬ 
ear  (Hadamard)  transformation  which  removes  some  of  the  inter¬ 
channel  correlation.  The  spectral  parameters  thus  require 

•l 

32/20  X  10  or  1550  bits  per  second  to  transmit." 


d.  Description  of  the  Microprogrammed  Vocoder 

Structure:—  The  vocoder  was  simulated  using  the  LX-1  simulator  on  TX-2. 

The  simulator  takes  input  samples  from  an  APEX  file  and  returns  the  vocoded  speech  to  that 
file.  A  20-cycle  delay  was  assumed  from  the  time  a  main  memory  read  or  write  request  is  is¬ 
sued,  until  the  request  is  completed.  However,  since  main  memory  operations  are  overlapped 
with  computation,  the  effective  delay  is  probably  three  cycles. 

Except  for  input/output,  and  input  buffer  maintenance,  the  vocoder  simulator  microcode  is 
identical  to  that  of  a  real  implementation.  The  I/O  operations,  however,  do  not  add  significant 
overhead  to  the  computations;  thus,  the  values  obtained  from  simulation  are  reasonable. 

There  are  three  main  loops  in  the  code: 

LOOP  1  This  calculation  is  done  every  lOOpsec  (if  real  time) 

and  involves  taking  the  discrete  Fourier  transform 


*  Semiannual  Technical  Summary  to  the  Advanced  Research  Projects  Agency  on  Graphics, 
Lincoln  Laboratory,  M.  I  T.  (30  November  1968),  DDC  679991. 
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of  the  current  sample  at  32  frequencies  (100  to  3200  cps) 
and  taking  the  running  sum  over  the  last  50  samples. 

LOOP  2  Every  50  samples  (every  5  msec),  the  sum  is  dumped 

and,  for  each  channel,  it  is  added  to  the  previous  5-msec 
sum.  We  thus  have,  every  5  msec,  the  sum  over  the  last 
100  samples.  The  magnitude  of  the  spectrum  of  each 
channel  is  calculated,  and  the  running  sum  over  the  last 
four  spectra  is  calculated. 

LOOP  3  Every  fourth  spectral  measurement  (every  20  msec),  the 

logarithm  of  the  sum  of  the  spectra  is  calculated,  and  the 
32  channels  are  compressed  to  16  by  appropriate  linear 
combinations  of  the  logarithms.  Finally,  the  sixteen  re¬ 
sults  are  multiplied  by  a  Hadamard  matrix  to  decorrelate 
the  channels,  and  the  channels  are  appropriately  quantified 
to  yield  a  total  of  32  bits  every  20  msec. 

Further  details  on  each  of  the  loops  follows. 

LOOP  1 In  the  current  implementation,  this  loop  is  approximately  50  micro¬ 
instructions  long,  plus  25  control  memory  words  where  the  sine  and  cosine  table  is  stored.  The 
calculation  of  the  current  sample  is  interleaved  with  reading  in  of  the  next  sample  from  control 
memory,  thus  the  latter  effectively  takes  no  time.  Only  one-quarter  of  both  the  sine  and  the 
cosine  waves  is  stored.  The  calculation  to  discover  which  table  value  to  use  and  whether  to 
complement  is  approximately  18  microinstructions  long  and  takes  from  9  to  18  cycles,  depending 
on  the  values  used.  The  average  is  13  cycles.  At  this  point,  we  have  loaded  the  appropriate 
values  for  the  sine  and  cosine  in  a  register.  These  must  be  separated,  multiplied  by  the  sample 
value,  and  the  result  added  to  the  running  sum.  This  section  is  approximately  19  microinstruc¬ 
tions  long  and  takes  from  17  to  44  cycles,  depending  on  the  values  used.  The  average  is  30  cy¬ 
cles.  The  calculation  for  LOOP  1  is  thus  45  cycles/channel,  or  1440  cycles/sample,  i.e., 
llSpsec,  assuming  80-nsec  cycle  time.  The  worst  case  is  around  I60psec;  the  best  case  is 
around  80  psec. 

LOOP  2  —  This  section  is  approximately  30  microinstructions  long  and  involves 
summing  the  value  of  the  previous  5-msec  sum  to  the  current  one.  The  previous  values  must 
be  read  in  from  external  memory  overlapped.  Finally,  the  magnitude  of  the  spectrum  is  taken. 

The  magnitude  taker  is  7  microinstructions  long  and  takes  from  4  to  7  cycles.  Setup  for 
taking  the  magnitude  is  6  cycles.  Taking  the  running  sum  and  testing  for  conditions  is  another 
6  cycles.  Thus,  approximately  18  cycles/channel  are  executed,  i.e.,  576  cycles  every  5  msec, 
or  48psec.  This  calculation  thus  adds  approximately  1  psec/sample,  if  the  input  samples  are 
buffered. 

LOOP  3:—  This  section  is  approximately  120  microinstructions  long.  The  log 
taker  is  15  microinstructions  long  and  takes  18  cycles.  The  channel  compressor  is  40  micro¬ 
instructions  long  and  takes  approximately  100  cycles. 

Calculating  the  Hadamard  coefficients  is  22  microinstructions  long  and  takes  approximately 
20  cycles/coefficient.  The  matrix  multiplication  itself  takes  6  cycles/element  including  setup 
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256  coefficients  x  ~30  cycles  ==^>  7680  cycles/spectrum 

Quantization  is  40  microinstructions  long  and  takes  ~100  cycles.  Thus,  the  total  is  18  x  32 
cycles  for  log,  100  cycles  for  compressor,  7680  cycles  for  Hadamard,  and  100  cycles  for  quan¬ 
tization,  i.e.,  8500  cycles  or  680fjisec  every  20msec.  If  the  input  samples  are  buffered,  this 
averages  out  to  approximately  4  fisec/sample. 

Discussion:—  All  times  and  cycle  values  are  approximate  and  are  on  a  per- 
sample  basis,  i.e.,  the  input  is  appropriately  buffered: 

Prototype  LSI 

Cycles  80  nsec/cycle  15  nsec/cycle 


LOOP  1 

1500 

120  jjLsec 

25  fasec 

LOOP  2 

15 

1  ^sec 

250  nsec 

LOOP  3 

50 

4  fasec 

750  nsec 

Overall 

1565 

1 25  fasec 

26  jasec 

The  above  implementation  shows  that,  with  the  anticipated  microprocessor  prototype  struc¬ 
ture,  the  analysis  of  input  speech  can  be  done  in  under  twice  real  time.  However,  two  factors 
have  not  been  taken  into  account:  the  maintenance  of  the  input  buffer,  and  the  section  of  the  an¬ 
alyzer  dealing  with  pitch  detection. 

It  can  also  be  seen  that  LOOPS  2  and  3,  even  though  they  are  long,  add  at  most  a  10-percent 
overhead  to  the  overall  calculation  if  a  200-sample  input  buffer  is  assumed.  In  order  to  achieve 
a  real-time  implementation,  therefore,  LOOP  1  must  be  optimized. 

Optimization  of  LOOP  T—  Two  improvements  can  be  made  to  LOOP  1  by  adding 

extra  hardware. 

(a)  Instead  of  storing  one-quarter  of  the  sine  wave  only  in  the  read-only 
memory,  a  full  cycle  could  be  stored  (100  registers),  thus  making  the 
decoding  for  the  table  lookup  much  faster.  The  table  would  have  to  be 
12  bits  x  100  words  long  and  be  accessible  in  one  cycle  time.  Lookup 
would  then  take  4  to  6  cycles,  instead  of  9  to  18  cycles.  With  these 
values,  LOOP  1  would  take  55}jisec  at  best,  and  128}xsec  at  worst. 

Thus,  this  change  alone  is  not  sufficient. 

(b)  A  hardware  multiplier  could  be  added  as  a  function  box.  Assuming 

it  could  multiply  in  one  cycle,  the  two  multiplies  and  adds  by  the  sine 
and  cosine  would  take  10  cycles  With  this  change  alone  (i.e.,  with 
only  a  quarter  sine  cycle  stored),  LOOP  1  would  take  55psec  at  best, 
and  80fjisec  at  worst.  Thus,  this  change  alone  is  sufficient  to  insure 
real  time  if  the  maintenance  of  the  input  and  output  buffers  and  pitch 
detectors  could  be  separate  hardware. 

If  both  these  changes  are  made,  LOOP  1  would  take  around  40}asec,  leaving  ample  time  for 
LOOPS  2  and  3. 


Conclusion:—  For  a  real-time  implementation,  the  current  microprocessor 
prototype  is  sufficient  if 

(a)  a  200-sample  (slow)  input  buffer  memory  is  added,  and 

(b)  a  fast  multiplier  is  added. 

A  100-word  read-only  sine-cosine  table  would  help  but  would  be  insufficient  alone  to  insure  real¬ 
time  operation. 
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e.  Other  Possible  Hardware  Modifications 


Instead  of  the  128-word  scratchpad  memory,  where  all  temporary  results  are  stored,  dy¬ 
namic  shift  registers  could  be  used  to  store  the  accumulations  of  sines  and  cosines,  as  well  as 
to  store  the  50-sample  sum  delays,  as  suggested  by  T.  Bially. 

f.  Conclusions 

The  LX-1  microprocessor  prototype  can  be  used  as  a  vocoder  analyzer,  with  some  modi¬ 
fications.  The  LSI  version,  which  should  be  five  times  faster,  could  certainly  be  used  with  no 
hardware  modifications  other  than  the  input  buffer,  and,  indeed,  might  be  fast  enough  to  be  used 
in  half-duplex  mode  for  both  analysis  and  synthesis. 

2.  Microprocessor  as  a  Display  Processor 

Work  is  currently  in  progress  on  applications  of  the  LX-1  microprocessor  as  a  display  con¬ 
troller.  The  speed  of  LX-1  and  its  very  flexible  I/O  characteristics  make  it  very  suitable  for 
this  application. 

Two  system  structures  are  currently  being  considered.  One  is  a  remote  terminal  serving 
several  scope  consoles,  with  a  disk,  perhaps,  for  bulk  storage.  The  other  is  a  system  using 
refreshed  scopes  running  partly  from  the  central  computer's  memory  and  making  calls  to  dis¬ 
play  subroutines  stored  in  the  LX-l's  local  memory.  The  objective  of  this  second  system  is  to 
reduce  the  load  on  the  central  computer  memory  due  to  cycle  stealing.  In  both  system  organi¬ 
zations,  the  microprocessor  would  perform  automatic  windowing. 

D.  Interactive  Computer-Mediated  Animation* 

A  Ph.  D.  thesis^  has  been  submitted  to  the  Electrical  Engineering  Department  at  M.I.T.; 
the  abstract  is  quoted  below: 

"The  use  of  interactive  computer  graphics  in  the  construction 
of  animated  visual  displays  is  investigated. 

"The  dissertation  presents  a  process  called  interactive  computer- 
mediated  animation,  in  which  dynamic  displays  are  constructed  by 
utilizing  direct  console  commands,  algorithms,  free-hand  sketches, 
and  real-time  actions.  The  resulting  "movie"  can  then  be  immedi¬ 
ately  viewed  and  altered. 

"The  dissertation  also  describes  a  special  kind  of  interactive 
computer-mediated  animation  that  exploits  the  potentialities  of  direct 
graphical  interaction.  The  animator  may  sketch  and  refine  (1)  static 
,  images  to  be  used  as  components  of  individual  frames  of  the  movie, 
and  (2)  static  and  dynamic  images  that  represent  dynamic  behavior, 
that  is,  movement  and  rhythm.  Because  these  latter  pictures  drive 
algorithms  to  generate  dynamic  displays,  the  process  is  called 
picture-driven  animation. 


*  A  portion  of  this  work  was  supported  by  Project  MAC  at  M.I.T. 

tR.M.  Baecker,  "Interactive  Computer-Mediated  Animation,"  Ph.  D.  Thesis,  Department  of 
Electrical  Engineering,  M.I.T.  (June  1969). 
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"Each  representation  of  movement  and  rhythm  determines  critical 
parameters  of  a  sequence  of  frames.  Thus,  with  a  single  sketch  or  ac¬ 
tion  that  generates  or  modifies  the  representation,  the  animator  can  ex¬ 
ercise  dynamic  control  over  an  entire  interval  of  the  movie.  One  natu¬ 
ral  way  to  do  this  is  by  mimicking  in  real  time  a  movement  or  a  rhythm, 
using  a  stylus  or  a  push-button. 

"These  concepts  are  supported  by  experience  with  three  special- 
purpose  picture-driven  animation  systems  which  have  been  implemented 
and  used  on  the  M.I.T.  Lincoln  Laboratory  TX-2  computer. 

"The  dissertation  also  presents  an  outline  of  the  proposed  design  of 
a  multi-purpose,  open-ended,  interactive  Animation  and  Picture  Proc¬ 
essing  Language.  A  PPL  is  a  conversational  language  which  accepts 
direct  sketches,  direct  console  commands,  and  algorithms  that  control 
interactive  dynamic  displays. 

"Solutions  are  presented  for  the  following  problems:  How  can  the 
system  be  structured  so  that  the  command  set  can  easily  be  augmented 
by  the  animator?  How  can  movie  time  be  represented  in  the  language, 
and  how  does  the  choice  of  representation  interact  with  the  flow  of  pro¬ 
gram  and  system  control?  What  computational  data  structure  can  fa¬ 
cilitate  the  modeling  of  sequential  and  hierarchic  structures  of  pictures 
and  dynamic  data9  How  can  we  provide  a  rich  picture  description  capa¬ 
bility  in  the  language?  How  can  we  facilitate  the  construction  of  pro¬ 
grams  which  describe  the  user’s  interaction  with  the  system? 

"APPL  programs  are  included  to  demonstrate  that  the  language  can 
be  gracefully  used  to  construct  dynamic  displays,  to  build  system  tools 
that  aid  the  construction  process,  and  to  implement  special-purpose 
interactive  computer-mediated  animation  systems  " 

Programs  implementing  selected  portions  of  the  concepts  developed  have  been  created  on 
the  TX-2.  The  initial  portion  of  an  animated  film  explaining  this  approach  to  animation  has  been 
created.  Figures  6(a)  and  (b)  show  two  different  scenes  from  a  short  cartoon  clip  from  this 
film,  and  Figs.  7(a)  and  (b)  show  pictures  which  define  and  drive  the  animation  actions  of  the 
cartoon. 

A  more  detailed  summary  may  be  found  in  a  paper  by  R.  M.  Baecker.v 

E.  Storing  of  Graphical  Inputs 

Exploratory  work  on  the  storing  and  later  reuse  of  interactive  graphical  inputs  has  been  re¬ 
ported  in  a  thesis. t  An  initial  implementation  of  this  capability  has  been  programmed  for  the 
TX-2.  Application  programs  which  use  the  input  replay  mechanism  can  now  be  written  even 
though  this  first  implementation  is  somewhat  inefficient.  It  is  possible  from  an  application 


*R.  M.  Baecker,  "Picture  Driven  Animation,"  Proc.  1969  Spring  Joint  Computer  Conference, 
Boston,  Massachusetts. 

tE.  L.  Thomas,  "The  Storing  and  Reuse  of  Real-Time  Graphical  Inputs,"  MS  Thesis,  Department 
of  Electrical  Engineering,  M.I.T.  (June  1969). 
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program  to  cause  the  storing  of  sequences  of  on-line  interactive  inputs,  to  observe  and  modify 
the  stored  input  stream,  and  to  play  back  a  stored  stream  to  the  program  as  though  the  inputs 
were  coming  directly  from  the  console.  The  implementation  is  particularly  oriented  toward  the 
data  tablet  as  the  principal  console  input  device. 

The  contents  of  a  stored  input  stream  can  be  observed  in  several  ways: 

(1)  As  a  text  representation  showing  condensed  information  about  each 
component  of  input 

(2)  As  a  graphical  representation  of  the  input  shown  in  its  proper  place 
on  the  display  screen 

(3)  As  a  sequence  of  inputs  viewed  in  a  movie-like  manner  one  after 
the  other. 

The  condensed  text  representation  is  used  for  deletions  and  insertions  by  positioning  a  cur¬ 
sor  to  the  appropriate  item.  New  input  can  be  added  by  drawing  directly;  however,  the  lack  of 
a  program  display  picture  context  makes  this  not  a  generally  useful  mode  of  input  extension. 
Deletion  of  extra  inputs  is  easily  accomplished  and  often  necessary  to  make  a  useful  stored  in¬ 
put  set. 

On-line  input  commands  can  be  inserted  in  the  stream  and,  when  encountered  by  the  play¬ 
back  system,  will  temporarily  halt  the  playback  until  a  live  input  is  entered.  This  input  is  used 
by  the  application  program,  then  the  playback  of  recorded  inputs  continues. 

Figures  8  through  11  show  pictures  of  the  recording  and  playback  system  in  action  within 
the  design  data  program. 

Initial  usage  of  this  kind  of  an  input  saving  appears  promising,  but  further  work  and  exper¬ 
imentation  will  be  needed  to  determine  the  real  potential  of  this  facility. 

F.  System  Performance  Measurement 

A  system  performance  measurement  facility  has  been  developed  for  the  APEX  time-sharing 
system. 

When  activated,  this  facility  records  the  occurrences  of  specified  events  in  the  running  of 
APEX.  Events  are  recorded  by  means  of  strategically  placed  subroutine  calls  to  a  program 
which  buffers  the  information  and  writes  it  out  on  secondary  storage  for  later  analysis. 

In  order  to  measure  scheduling  efficiency,  the  following  events  have  been  specified:  a  user 
moving  from  the  inactive  to  the  active  queue  (e.g.,  completion  of  typing  a  command),  a  user  being 
put  on  the  air,  the  breaking  of  a  user  before  completion  of  a  job  and  returning  him  to  the  active 
queue  (e.g.,  in-out  fault,  time  slice  expired),  and  a  user  completing  a  job  and  returning  to  the 
inactive  state.  With  each  event,  real-time  clock  value,  number  of  core  pages  used,  etc.,  arc 
also  recorded. 

The  two  plots  shown  in  Figs.  12(a)  and  (b)  were  obtained  by  analyzing  the  scheduling  events 
occurring  during  one  hour  of  APEX  activity  and  by  plotting  the  data  using  the  TX-2  Lincoln 
Reckoner  facilities.  The  plots  represent  waiting  time  (i.e.,  time  from  first  entering  the  active 
queue  to  completion  of  the  job),  in  the  horizontal  axis,  vs  the  amount  of  time  actually  spent  ex¬ 
ecuting  the  user's  instructions,  in  the  vertical  axis.  In  the  ideal  case,  all  points  would  lie  on 
the  diagonal,  indicating  that  all  of  a  user's  waiting  time  was  spent  executing  his  instructions. 

The  units  in  the  plots  are  numbers  of  microseconds;  to  avoid  bunching  toward  the  low  end,  log- 
log  (base  10)  plots  were  taken. 
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Figure  12(a)  covers  all  the  jobs.  The  cluster  of  points  at  about  10  to  50  msec  has  been  de¬ 
termined  to  be  the  heavy  usage  of  the  scope  text  editor;  each  movement  of  the  cursor  and  each 
insertion  or  deletion  of  a  character  is  an  individual  job.  The  proximity  to  the  diagonal  of  this 
cluster  indicates  the  comparative  efficiency  with  which  the  scope  text  editor  interactions  arc 
scheduled.  Elsewhere  on  the  plot  can  be  seen  jobs  running  for  other  periods  of  time;  some  of 
the  jobs  clearly  required  a  proportionately  large  amount  of  waiting  time  in  comparison  with  ex¬ 
ecution  time.  Points  at  the  lower  left-hand  corner  of  the  plot  are  far  from  the  diagonal  due  to 
the  relatively  large  amount  of  overhead  in  scheduling  a  job  that  runs  only  hundreds  of 
microseconds. 

Figure  12(b)  covers  only  the  jobs  which  required  running  and  waiting  times  in  excess  of 
1  00  msec. 

G.  Computer-Aided  Testing 

An  SEL810A  computer  with  8k  of  1 6 -bit  core  storage  and  a  225k  word-swapping  drum  has 
been  delivered  for  use  as  a  controller  for  automated  circuit  testing  Through  a  combination  of 
hardware  modifications  and  software  routines,  a  demand  paging  memory  organization  has  been 
implemented  and  is  working.  The  user  program  runs  as  though  it  had  available  128  pages  of 
512  memory  words  each.  Of  these  128  pages,  14  at  most  will  physically  be  in  core  storage;  the 
others  will  be  resident  on  the  swapping  drum.  If  the  program  attempts  to  reference  a  page  that 
is  not  in  core,  the  modified  hardware  will  trap  the  reference,  an  interrupt  routine  will  load  the 
desired  page  into  core  from  the  drum,  and  the  user  program  will  be  restarted.  When  no  free 
pages  are  left  in  core,  space  is  made  available  by  unloading  filled  pages  back  onto  the  drum. 

The  operation  of  this  paging  system  is  transparent  to  the  user  program. 

A  fixed-priority  multiprogrammed  executive  has  been  designed  to  run  within  this  virtual 
memory  system  and  is  currently  being  implemented,  lip  to  twelve  processes  can  be  run  beneath 
the  executive  on  a  fixed-priority  basis.  The  approach  is  different  from  that  of  a  general-purpose 
time-sharing  system  in  that  all  processes  operate  in  the  same  128-page  address  space  rather 
than  each  having  its  own  address  space.  The  processes  will  consist  of  a  user  program,  several 
i/O  handlers,  and  a  normally  dormant  interrogation  and  debugging  package.  In  the  event  of  sys¬ 
tem  failure,  control  will  be  passed  to  the  interrogation  package.  Normally,  control  will  be  with 
the  user  program  and  its  evoked  i/O  routines.  The  process  runner  will  attempt  to  give  control 
to  the  highest  priority  process  that  is  runnable.  In  the  event  of  a  missing  page,  lower  priority 
processes  will  be  freeloaded  when  possible  until  the  page  has  been  retrieved  from  the  drum. 
Processes  and  interrupt  routines  are  able  to  wake  up  other  processes  or  to  block  themselves 
pending  later  wakeup.  An  aggressive  paging  strategy  attempts  to  remove  from  core  pages  be¬ 
longing  to  blocked  processes. 

Except  for  the  inner  core  of  the  executive,  consisting  of  the  process  runner,  the  interrupt 
routines,  and  the  swapping  routines,  all  coding  is  being  done  in  BCPL,  and  is  being  compiled 
into  SEL  binary  files  on  the  TX-2.  The  executive  core,  the  total  length  of  which  is  less  than  one 
core  page,  is  written  in  assembly  level  language.  This  executive,  along  with  the  128-word  page 
table  and  a  few  hundred  words  of  global  variables,  is  the  only  part  of  the  system  frozen  in  core. 
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Fig.  1.  Microphotograph  of  on  entire  chip 
contoining  o  test  circuit  for  timing. 
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Fig.  2.  Microphotogroph  of  o  single  gate  in 
timing  chip. 


Fig.  3.  Sample  diogrom  drawn  with  design 
data  system. 
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Fig.  4.  LX-1  microprocessor  bus  organization. 


Fig.  5.  One  of  32  analyzer  channels. 
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Fig.  6(a-b).  Twa  scenes  from  a  short  cartoon  clip. 


-2-m 1 1 


Fig.  7(a-b).  Pictures  af  data  defining  animation  af  cartoon  clip. 
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(a) 


X— X 


(b) 


(c) 

Fig.  8.  (a)  Typical  stored  input  sequence;  (b)  display  of  each  of  inputs  superimposed;  and  (c)  effect  of 

inputs  in  a  particular  program  environment. 
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(a)  (b) 

Fig.  9,  (a)  Input  sequence  of  Fig.  8(a)  modified  to  include  an  on-line  input, 

and  (b)  replayed  until  occurrence  of  on-line  input. 
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(c) 

Fig.  10.  (a)  Inking  character  E  used  as  an  on-line  input  to  select  box  into  which  text  is  to  be  inserted, 

(b-c)  then  rest  of  input  sequence  is  replayed. 
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(  a  ) 

Fig.  1  l(a-b). 


(  b) 


A  different  box  is  selected  with  on-line  input. 


[-2-  8  796  ] 


(a)  (b) 

Fig.  12(a-b).  Response  performance  of  APEX  system  showing  plots  of  job  cpu  time 
(vertical  scale)  vs  total  job  time  (horizontal  scale). 
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